The present disclosure relates to event detection. In particular, but not exclusively, the present disclosure relates to detecting unusual communication session events in a telecommunications network.
Telecommunications networks are commonly employed to provide telecommunications services to end-users. These telecommunications services are generally orientated around communication sessions such as telephone calls and/or web services. These communication sessions include a series of “events.” For example, a call includes a “The calling subscriber has dialed some digits” event and probably a “The called subscriber is ringing” event, and maybe a “The called subscriber is busy” event.
Known service monitoring/troubleshooting network nodes (or ‘service assurance network nodes’) such as Metaswitch's™ Service Assurance Server™ (SAS) receive and store communication session events. Such network nodes typically have a user interface accessible via the Internet or other network (a ‘web interface’) by which administrators, support engineers or suchlike can search for specific communication sessions by various criteria (such as subscribers involved, time of day, etc.) and then display all the events generated on that communication session. When a service provider receives a complaint from a subscriber, the service provider can look up the failure and this is often sufficient to see why the communication session failed or contained errors. The service provider can then either explain to the subscriber what they did wrong, or fix their system if it is a misconfiguration.
Known network node products such as Metaswitch's™ Call Feature Server™ (CFS), Universal Media Gateway™ (UMG), Enhanced Application Server™ (EAS) and Perimeta™ Session Border Controller (SBC) each support generation of communication session events. Sometimes a communication session can span multiple of these products. For example, a communication session might come in via Perimeta SBC, be verified and passed on to CFS, which decides to set up a call and programs the UMG to handle media. Each of the systems generates a separate sequence of events, even though such events are part of the same communication session. The separate sequences of events can be referred to as “trails”. Such trails can be correlated together into a “trail group”, and it is this trail group that will typically be displayed to the administrator, support engineer or suchlike in a web user interface of a service monitoring network node.
FIG. 1 is a composite screenshot illustrating an example display of trail groups and communication session events. The upper-left image shows a single communication session, with a list of all events in a trail group in the top half and the details of a specific communication session event in the lower half. The lower-right image shows the list of all trail groups that match some example search criteria.
Whilst a service monitoring network node can be useful for troubleshooting communication session errors, a large trail group can contain hundreds of communication session events and it can be hard to find the interesting ones for error detection purposes, particularly for inexperienced service providers or support engineers.